Computing technologies have transformed our world. However, in order to prove useful, computing relies on the ability to access information. In the computing world, information is typically expressed as data structured in a specific defined structural form often referred to in the art as a “schema”.
For instance, a Simple Object Access Protocol (SOAP) envelope is a common message data structure expressed as a collection of eXtensible Markup Language (XML) elements. The SOAP envelope follows a set of rules (often called an XML schema) regarding the identity of the XML elements, the attributes of the XML elements, and the hierarchical relation of those XML elements. There are currently hundreds, if not thousands, of XML schema that define the form of various XML data structures. For instance, there may be different schemas for a SOAP envelope depending on the specific function of the SOAP envelope. A connection request SOAP envelope may have one XML schema, whereas a stock valuation report SOAP envelope may have a substantially different XML schema.
Schemas may be found outside the world of XML as well. For instance, a Remote Procedure Call (RPC) message follows a schema known in the art as ASN.1. In fact, any data that includes multiple interrelated fields may be said to have a schema.
It is often helpful to validate a data structure as truly following a given set of organizational rules or schemas. However, data structures can often undergo transformations not anticipated when the organizational rules and schemas were originally set up. For instance, consider the following example XML element that describes a purchase order:
<Purchase Order><ID> AC5003SEP05</><Vendor> ABC Patent Supply </><Total> $105.67</></Purchase Order>
When originally defining this XML element, the designer may define a schema for the Purchase Order element that includes three child XML elements; a first being a string representing the purchase order ID, a second being a string for representing the vendor name, and a third being a floating point value representing the total currency involved with the purchase order. That seems a completely reasonable and intuitive way for defining a schema for a purchase order XML element.
However, during the lifetime of that purchase order XML element, the element or portions thereof may undergo some transformation. For instance, as the purchase order XML element is transmitted from one location to another, it may be desirable to encrypt a portion of the element so as to hide information from public view. For instance, the total amount XML element may be encrypted if there is sensitivity to disclosing that amount. Furthermore, if bandwidth is limited, perhaps the content of the purchase order XML is compressed.
When performing validation of a data structure such as the example purchase order XML element, it is often only the untransformed data structure that is validated. When performing a validation, the various components of the data structure are compared against the expected structural rules in the form of a validation schema. If attempts are made to validate a transformed form of the data structure, the validation may fail since the structural rules may not recognize the transformed data structure as a valid interim representation of the data structure. For instance, if the entire content of the purchase order XML element is compressed, the validation engine will often not see the children XML elements, but will just see compressed content. Accordingly, validation may fail.
One alternative is to define several schemas for a particular data structure. For instance, one could define a second schema for the purchase order XML element in which the purchase order XML element has a single XML element named “Compressed Content”. However, this requires the generation and proliferation of a second schema. The data structure may be exposed to a variety of transformation including compression, encryption, digitally signing, and others so it may be cumbersome to work with a schema representing each permutation of possible transformations.